## Summary

Wire the new process plugin model into AMS so that table processes are discovered from `ProcessFactory` implementations and scheduled via the existing `ProcessService`.

## Details

- Extend `DefaultTableRuntimeFactory` to implement the `TableRuntimeFactory` process APIs:
  - Aggregate installed `ProcessFactory` instances by `TableFormat` / `Action` and expose derived `ActionCoordinator` plugins via `supportedCoordinators()`
  - Merge `DefaultTableRuntime.REQUIRED_STATES` with additional states required by all process factories for the same format when building `TableRuntimeCreator`
  - Keep using `DefaultTableRuntime` without introducing extra runtime types
- Introduce `DefaultActionCoordinator` to bridge `ProcessFactory` trigger/recover semantics to the existing scheduler:
  - Build trigger strategies from `ProcessFactory#triggerStrategy`
  - Delegate `trigger` and `recoverTableProcess` to the underlying factory
- Add `TableProcessFactoryManager` as an `AbstractPluginManager<ProcessFactory>` using the `process-factories` plugin namespace
- Refactor `AmoroServiceContainer` startup sequence:
  - Initialize `TableProcessFactoryManager` and collect all installed `ProcessFactory` instances
  - Initialize all `TableRuntimeFactory` plugins with the shared list of process factories
  - Collect all derived `ActionCoordinator`s from table runtime factories and inject them into `ProcessService`
- Update `ProcessService` to accept a pre-built list of `ActionCoordinator`s while keeping the original constructors for backward compatibility and tests
- Run `mvn spotless:apply` and `mvn -pl amoro-ams -am -DskipTests compile` to ensure style and compilation pass

Co-Authored-By: Aime <aime@bytedance.com>
Change-Id: Iaa867503c8b0bf93c2b7f0b8fe7d752e2ddbac67

…in and use default runtime

## Summary

Decouple `TableRuntimeFactory` from the generic `ActivePlugin` mechanism and make `AmoroServiceContainer` explicitly use `DefaultTableRuntimeFactory` as the default implementation.

## Details

- Change `TableRuntimeFactory` in `amoro-common` so it no longer extends `ActivePlugin`, keeping only process-related APIs:
  - `List<ActionCoordinator> supportedCoordinators()`
  - `void initialize(List<ProcessFactory> factories)`
  - `Optional<TableRuntimeCreator> accept(ServerTableIdentifier, Map<String, String>)`
- Refactor `TableRuntimeFactoryManager` in AMS:
  - Remove inheritance from `AbstractPluginManager<TableRuntimeFactory>` to avoid the `ActivePlugin` constraint
  - Implement a simple manager that wraps a provided `List<TableRuntimeFactory>`
  - Provide a default no-arg constructor that installs a single `DefaultTableRuntimeFactory`
  - Keep `initialize()` as a no-op and `installedPlugins()` as the accessor to preserve existing wiring in `DefaultTableService`
- Update `DefaultTableRuntimeFactory`:
  - Remove `@Override` annotations from `open/close/name` since they no longer implement `ActivePlugin` methods
  - Keep the methods as no-op helpers with the same behavior
- Update `AmoroServiceContainer.startOptimizingService` to use `DefaultTableRuntimeFactory` directly:
  - Construct a `DefaultTableRuntimeFactory` instance explicitly
  - Wrap it into `TableRuntimeFactoryManager` via `Collections.singletonList(tableRuntimeFactory)`
  - Use the resulting singleton list as the only table runtime factory when initializing process factories and collecting `ActionCoordinator`s
- Leave `DefaultTableService` logic unchanged, it still uses `TableRuntimeFactoryManager.installedPlugins()` but now operates over the explicit default factory list
- Ensure `ProcessService` changes from previous step are included in this commit so the module compiles cleanly

## Verification

- Ran `./mvnw -pl amoro-ams -am -DskipTests compile` from repo root
  - Build succeeded for the full AMS reactor
  - `spotless` and `checkstyle` passed with only existing warnings unrelated to this change

Co-Authored-By: Aime <aime@bytedance.com>
Change-Id: Ifa8deef0d2553176300cdef2c0cb073d52ee3303